Amazon FSx for NetApp ONTAPに移行したいと言われた時にヒアリングすることn選

最近よく聞かれるのでまとめてみます

こんにちは、のんピ(@non____97)です。

皆さんは「Amazon FSx for NetApp ONTAP(以降FSx for ONTAP)に移行したい」と言われたことはありますか? 私はあります。

私が布教活動をしている影響か、FSx for ONTAPへの移行の相談をいただくことがあります。

正直FSx for ONTAPだからといって、そこまで特殊な考慮事項はあまりありません。

ただし、ファイルサーバー移行時に共通的に役立つこともあるかなと思ったのでまとめてみました。FSx for ONTAP関係なくファイルサーバーの移行をする時などに参考にしてみてください。

記載のヒアリング項目で以下の内容を把握します。

• FSx for ONTAPへの移行の妥当性
• 大まかなネットワーク構成
• ランニングコスト
• 移行時のリスク

移行の背景や課題の確認

Q. 移行の背景と目的

まずは、移行の背景と目的を確認しましょう。

移行によって何を達成したいのかを把握しなければ、何を持って「移行が成功した」のか判断することができません。

相談してきた方がどのような経緯で「移行をする」という選択を取ったのかの背景を整理します。

例えば以下のようなものが挙げられます。

• 1年後に保守切れなので、移行先の候補を探している
• 現行ファイルサーバーの空き容量が残り数100GBで、拡張することもできない。急いで移行先を見つける必要がある
• パフォーマンス不足で業務に影響が出ている

また、行き当たりばったりの設計や対応を防ぐためにも、移行時や移行先に対して何を重要視しているのかの目的や前提条件を整理しましょう。

以下を軸にヒアリングをします。

• コスト
• パフォーマンス
• セキュリティ
• 可用性
• 運用の簡便さ
• スケジュール

ヒアリングした内容全て満たすことを難しい場面は多々あります。そのため、必ず優先度と、その優先度に至った経緯も確認しましょう。

Q. 現行環境から改善したいポイント

現行環境についての不満点あるなしに関わらず、改善したいポイントがあれば確認します。

「現行踏襲」として単純にデータを移行するだけでは、今現在抱えている課題を解消することができないこともあります。

認識している課題や「移行後はこうしたい」という改善ポイントをざっくりと確認します。

例えば、以下のようなものが挙げられます。

• 運用負荷が高いので、マネージドサービスでできるだけメンテナンスフリーで運用したい
• 1ボリュームの配下に全てのデータが保存されているので、組織毎にボリュームを分割したい
• 特殊な文字を扱いたいので、ファイル名に4バイト文字を扱えるようにしたい
• 監査で指摘されたため、遠隔地にバックアップを転送したい
• テレワークの対応として、インターネット上からデータにアクセスできるようにしたい

ヒアリングする場合は、その背景や重要度も確認しましょう。「挙げてはみたが、必ず満たす必要はない」という場合もあります。

Q. FSx for ONTAPに期待していること

「現行環境から改善したいポイント」とニュアンスが重複していますが、何故「FSx for ONTAPに移行したい」と思ったのか確認します。

内容によっては、FSx for ONTAPで満たすことができないことがあるかもしれません。実現したいこととFSx for ONTAPがミスマッチしていないのかを把握しましょう。

また、使用してみたい機能があるのかも確認してみます。

Q. 今後のAWS利用の展望

どのAWSアカウント上で構築するのかや、どのようなネットワーク構成にするのかを整理するために確認します。

1つのFSx for ONTAPファイルシステムを全社統一的に使うのであれば、専用のAWSアカウントやVPC上に作成することになるかと思います。

既存システムの専用ファイルサーバーとして使用するのであれば、そのシステムのAWSアカウント上に作成することになります。

Q. FSx for ONTAPへの移行で心配している点、気になっている点

何か懸念されている点があればヒアリングします。

その場で回答できそうなものがあれば回答します。即答できた場合も「気にされているポイント」として議事録に記録しておきましょう。

移行元のONTAPやファイルサーバーの用途についての確認

Q. どんなワークロードで使用しているのか

移行元のONTAPやファイルサーバーがどのようなワークロードで使われているのかを確認します。

例えば以下のようなものが挙げられます。

1. 一般的なクライアントPCへのファイル共有
2. データ分析
3. 動画のレンダリング

各種スペックやネットワーク構成などの設計する際の材料となります。

クライアントPCからのアクセスのみで、インターネット越しの接続がOKなのであればGoogle DriveやBoxなどのファイル共有サービスを使った方が幸せな場合もあります。

Q. 移行対象のファイルサーバーとボリューム、ファイル共有数

ファイルサーバーが1台とは限りません。作業ボリュームを把握するために確認します。

また、複数のファイルサーバーを1つのFSx for ONTAPファイルシステムにまとめたいという場面もあったりします。

まとめる場合は、SVMを分けるのかどうかも確認しましょう。

Q. 使用するプロトコルは何か

NFSやSMBのファイルサーバーとして使用しているのか、それともiSCSIで接続しているのかを把握しましょう。

また、NFSとSMBどちらも使用する場合は、1ファイルに対して両方のプロトコルでアクセスできるようにしているのかも確認しましょう。設計難易度に跳ねてきます。

Q. アクセス元のロケーションやクライアントは何か

ネットワーク構成やFSx for ONTAPの設定内容に影響あるので確認します。

確認観点としては以下になります。

• アクセス元のロケーションの種類
  • オンプレからのアクセスのみか
  • AWSからのアクセスのみか
  • それとも両方か
• アクセス元のロケーションの数
  • アクセスしてくる拠点数、VPCの数はどの程度あるか
  • 各拠点、VPCとの通信経路はどのような想定をしているのか
  • 拠点間VPNを介さずにインターネット越しにアクセスしてくることはあるのか
• クライアントの種類
  • ファイルサーバーにアクセスするのはヒトか
  • サーバーからもマウントするか
• クライアントOS
  • Windowsからのみのアクセスか
  • macOSやLinuxからもマウントするか
• 使用するプロトコル
  • SMB 1.0を使用する必要があるか
  • NFSv3を使用する必要があるか
• 同時接続数
  • どの程度の数のクライアントが接続してくるのか

オンプレから大量にアクセスがある場合はDirect Connectを引いたり、Transit Gatewayを用意する必要があったりする際の判断材料になります。

Q. 求められるスループットやIOPS

FSx for ONTAPで設定可能な値かどうかを確認します。

「高い性能を求めているが、Site-to-Site VPNやDirect Connect越しにアクセスする必要がある」という場合、ネットワークがボトルネックになりがちです。

その場合はオンプレミスにFlexCacheを配置することを検討します。

Q. 求められる可用性

99.9% などの数値だけでなく、「アクセスできなくなったら全業務が停止してしまう」など停止した場合の影響度合いも確認します。

また、ノード障害だけでなく、AZ障害やリージョン障害時のRPO/RTOについても確認しておきましょう。Multi-AZでデプロイするのか、別リージョンにもデプロイするのかの判断材料になります。

FSx for ONTAPはSingle-AZであっても、2つのノードが存在しています。

AZ障害時は日次で取得しているバックアップからリストアする形でOKであれば、Single-AZで十分だったりします。

なお、2023/7/23時点でFSx for ONTAPは大阪リージョンに対応していません。バックアップを遠隔地に転送したい場合はシンガポールやソウルなど日本外のリージョンに転送する必要があることに留意しましょう。

また、FSx for ONTAPはAWS Backupで別リージョンにバックアップを転送することはできません。バックアップを遠隔地に転送したい場合はSnapMirrorやSnapVaultを使用する必要があります。

Q. 週次でのメンテナンスを許容できるか

FSx for ONTAPでは必ずメンテナンスウィンドウを指定する必要があります。メンテナンスウィンドウを設定するタイミングがあるのか確認します。

メンテナンス時にフェイルオーバーが発生しますが、中断なく接続を継続することができるとされています。

ただし、高スループット、高IOPS、低レイテンシーが要求されるワークロードにおいてはメンテナンス時に60秒未満の性能影響を受けることがあるようです。

抜粋　: Amazon FSx for NetApp ONTAP AWS Black Belt Online Seminar P.39

ワークロードのピーク時間を把握する意味でも確認しておきましょう。

Q. 移行後の環境で満たしたい機能要件、非機能要件

「取得したバックアップは誰にも削除できないようにしたい」や「ユーザー毎に保存できるデータ量のクォーターを設定したい」、「ファイルアクセスの監査ログを出力する必要がある」、「現行環境と同じDNS名でアクセスできる必要がある」など現時点で見えている機能要件、非機能要件があれば確認します。

その場で全てを完全に整理することは難しいので、詳細はプロジェクトが始まってからでも良いでしょう。

ただし、プロジェクトとして必ず満たす必要がある前提条件のようなものがあれば早めに把握しておきます。

また、参考情報として現行環境の非機能要件も確認しましょう。

Q. 現行環境で使用している機能

オンプレのONTAPではサポートしているが、FSx for ONTAPがサポートしていない機能があるので確認します。

例えば、2023/7/23現在ではSVM-DRやSnapMirror Synchronous、Autonomous Ransomware ProtectionはFSx for ONTAPではサポートしていません。

実行可能なコマンドは以下記事で紹介している方法で確認可能です。

ただし、物によっては実際にコマンドを叩いて意味なければサポートしているのか分かりません。検証環境があるのであれば設定可能かどうか検証してみましょう。

扱うデータについての確認

Q. 総データサイズの確認

移行期間や移行方法、ランニングコストに影響があるので確認をします。

データサイズは「使用中のデータサイズ」を確認しましょう。プロビジョニングされたボリュームサイズではありません。

また、重複排除・圧縮をかけている場合、どの程度かかっているのかも確認します。SnapMirror以外で移行する場合重複排除・圧縮が解除された状態でデータが転送されるためです。

FSx for ONTAPのSSDやボリュームのサイズの見積もりは以下記事を参考にしてください。

Q. ファイル数と1ファイルあたりの平均サイズ

DataSyncやSnowball Edgeを使って転送する場合、ファイル数が多かったり、階層が深かったりすると転送に時間がかかります。(SnapMirrorで転送する場合はファイル単位ではなくデータブロック単位で転送するので影響ありません)

DataSync Agentを使う場合は、DataSync Agentのスペックに関わるので確認しましょう。

サイズが小さいファイルが大量にある場合はzipで固めてから転送するのも手です。

また、ファイル数やフォルダ数はinodeを拡張する必要があるのかの判断材料になります。

Q. 1ファイルの最大サイズ

ONTAPのファイルシステムであるWAFLが扱える1ファイルの最大サイズは16TB128TBです。

研究データなどを扱う場合は超過する可能性があるので確認します。

2024/1/18 追記 : ONTAP 9.12.1から単一のファイルサイズやLUNのサイズが128TBに拡張しています。併せてFlexVolumeのサイズ上限も300TiBに増加しています。詳細は以下記事をご覧ください。

Q. アクセス頻度

アーカイブとして、大量のデータを保管しておきたい時の置き場所として使われる場合があります。

FSx for ONTAPではFabric Poolという機能により、アクセス頻度の低いデータブロックを安価なキャパシティプールストレージに階層化することができます。

上手く使えば大きくランニングコストを削減することができます。そのためにも、どのぐらいの割合のデータが頻繁にアクセスされるのか、高速な読み込みが必要なのか確認しておきましょう。

Q. データの増加量

ランニングコストの見積もりのために確認します。

FSx for ONTAP自体はキャパシティプールストレージを使うことで実質無制限にデータを保存することが可能です。(実際は20PBほどまで)

キャパシティプールストレージがスケールする & 安価とはいえ、保存量が増えれば課金額も増えます。大きくデータ保存量が増えるのであれば、コストに大きく跳ねるため増加量は把握しておきましょう。

Q. その他クォータに抵触する可能性があるか

1ファイルシステムにアタッチできるボリュームの数など上限があります。事前に抵触する可能性があるものがないかチェックしましょう。

認証についての確認

Q. 認証はどのようにして行なっているか

SVMのSMBサーバーをドメイン参加させたり、LIFでLDAPの設定をする必要があるのかを判断します。

クライアントがADやLDAPを使ってKerberos認証するのか、それともNTLM認証をするのか、はたまたファイルサーバー内のローカルユーザーで認証しているのか確認しましょう。

Q. 認証先や認証方法を変更するか

移行のタイミングで認証に使用するサーバー(AD DCなど)を変更する可能性も確認します。

個人的にはオンプレミスにしか認証に使用するサーバーがいないのは、Direct ConnectやSite-to-Site VPNが切断した場合の影響が大きいため、あまりお勧めしません。(クライアントがオンプレミスにしかいないのであればあまり気に知る必要はありませんが)

もし、可能であれば認証に使用するサーバーをAWS上にも構築することを検討しましょう。

運用についての確認

Q. 普段行っている運用

現在行っている運用がFSx for ONTAP上でも実現可能かどうかを確認します。

併せて、本当に継続してその運用をする必要があるのかも精査すると良いでしょう。

Q. ONTAPに対する習熟度

FSx for ONTAPの設定変更や運用をする場合、ONTAP CLIを使うことが多いです。

ONTAP CLIでは辛いのであれば、BlueXP導入も検討します。BlueXPを使用することでブラウザ上からGUIでFSx for ONTAPの操作が可能になります。一方でBlueXPを使用する場合はコネクター用のEC2インスタンスが必要になるので注意してください。

移行についての確認

Q. 移行にかけられる時間

移行スケジュールを立案するために確認します。

絶対に後ろにずらすことができない要素があるのかも確認します。もし、そうなのであればその理由を確認します。

保守切れの場合も延長が可能かどうか事前に把握しておきます。

個人的には時間をかけて移行するのが、重複排除・圧縮が効きやすいオススメです。

Q. データ移行および切り替えが可能な時間帯

「現行環境への負荷を考慮して休日の特定時間しかデータ転送ができない」や「切り替え日時は2023/7/29のAM 1:00からと決定している」など、移行時間についての前提条件を確認します。

「xx日前に伝えれば業務調整が可能」のような条件があるかもチェックすると良いでしょう。

Q. 移行元から移行先への回線速度や回線品質

DataSyncやSnapMirrorを使用する場合、ファイルサーバー間で通信が発生します。移行で使用できる回線の速度と回線品質を確認します。

また、Direct ConnectやSite-to-Site VPNで使用している回線のみではなく、オンプレミスのスイッチやルーターがボトルネックにならないようにエンドツーエンドの帯域を確認しましょう。

できれば通常時の負荷状況も確認すると良いでしょう。

Q. Transit VIFを用意できるか

要件としてAZ障害時も短いRPO/RTOが求められる場合、FSx for ONTAPファイルシステムをMulti-AZでデプロイする必要があります。

以下記事で紹介している通り、Multi-AZでデプロイする場合はTransit Gatewayが必須です。

オンプレミスとの通信でDirect Connectを用意するレベルで高品質な回線が必要である場合はTransit VIFの用意が必須となります。

しかし、Direct ConnectのパートナーによってはTransit VIFを用意することが難しいこともあるので要チェックです。

難しい場合は、インターネット回線を使うSite-to-Site VPNでも良いか、Single-AZでデプロイする形でも良いのかを検討します。

また、他システムで使っている回線があるのであれば相乗りすることが可能かも確認します。

Q. 現行環境の運用保守ベンダーからサポートを受けられるか

場合によっては現行環境の設定変更が必要になります。

現行環境の運用保守ベンダーにて設定や調査ができるか確認しておきましょう。

Q. 現行環境のONTAPのバージョン

ONTAPのバージョンが離れすぎるとSnapMirrorをすることができません。

具体的には6つ以上バージョンが離れたSnapMirrorをすることはできません。(ONTAP 9.12.1とONTAP 9.7間は可能だが、ONTAP 9.12.1とONTAP 9.6間は不可)

FSx for ONTAPではONTAPのバージョンを固定化することはできません。そのため、計画立案時はSnapMirrorで移行できる想定だったのに、いざ移行しようとすると移行できなかったみたいなことがあります。

大体半年に1回ぐらいにバージョンアップする想定をすると良いでしょう。

可能であれば現行環境のONTAPのバージョンを上げることができるかも検討します。

Q. SnapMirrorのライセンスを用意できるか

SnapMirrorを使用して移行する場合、ライセンスが必要なので調達可能か確認します。

移行元がONTAPであれば、SnapMirrorを使うのが手っ取り早いです。SnapMirrorで移行することで圧縮・重複排除が効いた状態で転送できます。

ただし、移行元、移行先が同じ構成になるため ボリュームの構成やディレクトリ構成を変更したい場合には 移行後に手動で変更が必要です。

ちなみに、FSx for ONTAP間のSnapMirrorはライセンス不要です。

コスト

月額の予算感

月額のランニングコストとしてどのぐらいを想定しているのかを確認します。

また、既に予算どりをされているのか、調整が可能かどうかも確認します。

あまりにも想定と見積もりした金額が離れている場合は代替案を検討します。

移行プロジェクトの予算感

月額の予算とは別に、移行プロジェクトとして掛けられるコストについても確認しておきます。

Classmethod Cloud Guidebookと組み合わせながらヒアリングしてみてください

Amazon FSx for NetApp ONTAPに移行したいと言われた時にヒアリングしたいことを紹介しました。

ヒアリング項目は取捨選択をして、FSx for ONTAPへの移行限らずファイルサーバー移行で役立ててください。

ヒアリングする項目だけでなく、ファイルサーバー移行のプロセス全体が気になる方はClassmethod Cloud Guidebookをご利用ください。

Classmethod Cloud Guidebookでは「データ移行ガイド」としてAWSにデータを移行するための準備や流れについて記載した情報を公開しています。クラスメソッドメンバーズをご利用されている方は閲覧することが可能なので、ぜひご覧ください。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!